「Wow~~沒想到阿宅 PO 竟然撐過 20 天了！！！」
「再加把勁，剩下 10 天用力扛過去！！！」

今天來介紹前端工程師必定會遇到的 Web API
但實務上，阿宅 PO 在專案上遇到 Web API 時，卻是再講兩種不一樣的 API

• 一種是 瀏覽器提供的 API (EX: MDN Web API)
• 一種是 後端提供的 API (EX: 公司產品的 API)

提供給各位捧油參考一下
接下來進入正題啦～～首先來介紹 「什麼是 API？」

API

API 是 Application Programming Interface 的縮寫
中文翻譯是「應用程式介面」。

這邊推薦一下這篇文章
「API 到底是什麼？ 用白話文帶你認識」
裡面有提到一部影片，講解得十分白話，非常推薦新手們服用！

大意是說，想像 網站 就像是一間餐廳，而 API 就像是餐廳內的服務生
當我們向服務生點餐 ( 發出 Require )，而服務生幫我們餐點需求，送到後台廚房 資料庫，等廚房將餐點調理好，再由服務生 API 將餐點 ( Respons ) 送到我們桌上。

API 就像是我們跟另一個端口溝通的一條資料管道 / 介面。

而 API 這個概念不是只有在 Web 技術上，在其他 IT 領域都會用得到
像是阿宅 PO 之前的其中一份工作，網站系統是需要與硬體設備溝通
所以就需要透過跟 韌體 對接資料，以取得硬體設備的資訊
像這樣的情境就會有 韌體端 / 中間層 提供的 API，供我們網站系統讀取或寫入資料使用。

這個時候，最常會碰到的疑問就是：
「到底要怎麼知道或決定這個 API 介面由誰提供呢？」

這個問題阿宅 PO 剛開始也是一臉疑惑
但在實際跑過幾次專案 / 產品之後，自己歸納出了以下結論
提供各位轉職的設計師 / 新人捧油一點方向

由哪一端提供 API，大多會在專案建置初期或中期，由團隊討論決定。
但，前端的工作內容特性多以「整合資訊」為主，所以 API 大多會是其他需要將資訊整理到畫面上的那一方提供，讓前端可以取得資料並渲染到畫面上。

今天主要是介紹 API 是什麼
此次 API 的章節會細分成 三 章來跟各位捧油分享

明天會介紹 API 常用的文件格式 JSON
大家不要錯過囉！我們明天見～～～